Different congestion control mechanisms have been developed. Up to now all congestion control mechanisms assumed the same congestion to feedback function, i.e. packet drop or delay on a tail-drop queue, and a fair response to packet drop is to respond as a function that approximates the Transmission Transport Protocol (TCP) Reno algorithm. To avoid latency, alternative mechanisms are needed; however, these alternative mechanisms do not match either the average queuing delay or packet loss probability of TCP Reno. Data Center TCP (DCTCP) is an example of such an alternative mechanism, but other congestion control mechanisms are also possible.
Today it is not possible or accepted to deploy Active Queue Management (AQM) and congestion controllers that are not ‘TCP friendly’. New initiatives are restricted to walled deployments separated from the internet, e.g. Data Centers. Some improvements are made, but some kind of ‘TCP friendly’ behavior is expected, and the more a new congestion control mechanism deviates from this, the more resistance the protocol gets for deployment. Further, dedicated in-network measures have to be taken to enforce the flows to meet the fairness metrics, e.g. Fair Queuing.
Today the different traffic types are separated in different ‘pipes’ with different capacities assigned to them, independently of the number of flows that are active in them. One pipe can be overloaded with many flows each getting only a small amount of bandwidth, while the other pipe might have only a few flows each getting a big amount of bandwidth.